Cryptographic Asset Collateral Management

ABSTRACT

Embodiments include systems and techniques including a system configured to obtain a first secured obligation of an obligor to a first obligee. The system is configured to transfer cryptographic assets from an account owned by the obligor to an account owned by the first obligee. The system is configured to obtain a second secured obligation of the obligor to a second obligee. The system is configured to instantiate a smart contract which transfers at least a portion of the cryptographic assets from the account owned by the first obligee to an account owned by the second obligee when the first secured obligation is satisfied. The system is configured to determine that at least some of the obligation of the obligor to the first obligee has been satisfied. The system is configured to cause execution of the smart contract.

PRIORITY

This application is a continuation under 35 U.S.C. § 120 of U.S. patentapplication Ser. No. 17/001,385, filed 24 Aug. 2020, now U.S. Pat. No.11,538,105, which is incorporated herein by reference.

BACKGROUND

Virtual currencies, like cryptocurrencies, have generated enormousinterest since the publication of the Bitcoin whitepaper in 2008.Bitcoin and other cryptocurrencies (and other types of cryptographicassets) have facilitated transactions worldwide, often in jurisdictionswhere commerce would otherwise be challenging, like those withless-developed financial markets and less-robust support for the rule oflaw. And even in jurisdictions that are more favorable for commerce, useof cryptocurrencies has expanded to facilitate transactions with greaterprivacy and lower transaction costs than would otherwise be available insome cases. Indeed, it is expected that the importance ofcryptocurrencies will only increase, as the related technical, legal,and social infrastructure matures.

BRIEF DESCRIPTION OF THE DRAWINGS

The above-mentioned aspects and other aspects of the present techniqueswill be better understood when the present application is read in viewof the following figures in which like numbers indicate similar oridentical elements:

FIG. 1 is a block diagram of an example of a computing environment inwhich cryptocurrency collateral may be managed, in accordance with someembodiments;

FIG. 2 is a flow chart of an example of a process to managecryptocurrency collateral, in accordance with some embodiments;

FIG. 3 is a flow chart of an example of a process to update state of aloan secured by cryptocurrency, in accordance with some embodiments;

FIG. 4 is a block diagram of an example of another computing environmentin which cryptocurrency collateral may be managed, in accordance withsome embodiments;

FIG. 5 is a block diagram of an example of a blockchain-based computingplatform, in accordance with some embodiments; and

FIG. 6 is a block diagram of another computing environment in whichcryptocurrency collateral may be managed, in accordance with someembodiments.

While the present techniques are susceptible to various modificationsand alternative forms, specific embodiments thereof are shown by way ofexample in the drawings and will herein be described in detail. Thedrawings may not be to scale. It should be understood, however, that thedrawings and detailed description thereto are not intended to limit thepresent techniques to the particular form disclosed, but to thecontrary, the intention is to cover all modifications, equivalents, andalternatives falling within the spirit and scope of the presenttechniques as defined by the appended claims.

DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS

To mitigate the problems described herein, the inventors had to bothinvent technical solutions and, in some cases just as importantly,recognize technical problems overlooked (or not yet foreseen) by othersin the fields of fintech, cryptography, and decentralized systems andapplications. Indeed, the inventors wish to emphasize the difficulty ofrecognizing those problems that are nascent and will become much moreapparent in the future should trends in industry continue as expected.Further, because multiple problems are addressed, it should beunderstood that some embodiments are problem-specific, and not allembodiments address every problem with traditional systems describedherein. That said, improvements that solve various permutations of theseproblems are described below.

Holders of virtual assets (like virtual cryptographic assets, such asdigital assets rendered rivalrous with distributed ledger technology)often find it difficult to borrow against those assets, using them ascollateral. This issue is particularly acute in the realm ofcryptocurrency, given the relatively substantial amount of stored valuethat has accrued. For a variety of reasons, users may want to pledgecryptocurrency (or other virtual cryptographic assets, like utilitytokens) as security against various types of obligations, likepromissory notes or promises to perform some service. Secured loans canbe preferred over outright sales of the virtual cryptographic assets fora variety of reasons. For instance, often asset-owners wish to retainownership of the virtual cryptographic assets to avoid tax consequencesof a sale or to maintain exposure to price changes in the assets andparticipate in appreciation.

Challenges arise when attempting to borrow against virtual cryptographicassets using many forms of distributed ledger technology. (Much of thediscussion that follows is with reference to cryptocurrency, but itshould be appreciated that similar approaches are contemplated for othertypes of virtual cryptographic assets, like utility tokens, nonfungiblecryptographic assets (e.g., ERC-721 tokens), and the like.) Onechallenge is volatility of the price of cryptocurrency. Many types ofcryptocurrency fluctuate in value relative to other assets, likegovernment-issued currency, such as the US dollar, or stable coincryptocurrencies pegged to the value of one or more forms ofgovernment-issued currency. Often, these fluctuations are relativelylarge compared to what is experienced in more typical lending practices.A concern is that a downward fluctuation could leave cryptocurrencycollateral worth substantially less than the obligation being secured,reducing (or even eliminating) the lender's protection from default. Asa result, many lenders have been unwilling to lend againstcryptocurrency (e.g., with the cryptocurrency securing the obligation torepay) because existing forms of distributed ledger technology often donot provide sufficient tools and functionality to manage that volatilityover the life of the loan. Further, many forms of distributed ledgertechnology impose more latency on, and offer less bandwidth to process,transactions than would be preferable, particularly if such systems wereever tasked with processing a material portion of (e.g., more than 2%of) more established forms of off-chain transactions, like credit cardtransactions. For instance, it has been estimated that the Bitcoinnetwork can process around 7 transactions per second, while credit cardtransactions are estimated to occur at closer to a rate of 5,000 persecond.

Another challenge with lending against cryptocurrency arises from thefailure of many existing computer systems to accommodate the legalbackground governing how security interests are perfected. Perfecting asecurity interest may include creating records that are legallyrecognized as putting others on notice that the security interestexists, to prevent others from later lending against the same asset andtaking a superior position in the event of default (e.g., being ahead inline to be compensated by sale of the collateral upon default whenmultiple lenders have taken security interests in the collateral).

The form this notice takes is often specified by the Uniform CommercialCode (UCC). A number of scholars of the same have taken the positionthat, under the UCC, many forms of cryptocurrency qualify as “generalintangibles,” placing them in the same category as commercial tortclaims, deposit accounts, letters of credit, and other rightsrecoverable with legal claims. A consequence of this classification,under the UCC, is that perfection typically involves recording afinancing statement (e.g., a UCC-1 form) with a governmental entity inthe grantor's (e.g., the lender's or guarantor's) home state to putjunior lean holders on notice. Further, ensuring that a senior lien doesnot currently exist, before agreeing to lend against the asset, ofteninvolves searching public records for such statements. Complicating theprocess even further, security interests can run with the asset in somecases, meaning that a unit of cryptocurrency could be burdened by asecurity interest granted by previous owner in some cases.

The technical complexities of accurately checking for senior liens andperfecting through filing financing statements has deterred many fromlending against cryptocurrencies, as many existing forms of distributedledger technology are not well suited to mitigate the risks otherwiseaddressed by (or created by) these processes. Among other issues is the“oracle problem,” which is a long-felt problem in the realm ofdistributed ledger technology. The problem arises from the security andauthenticity of data from third-party oracles (e.g., sources of datamaking assertions upon which smart contract logic flow branches) and thetrustless execution of some forms of smart contracts. Some users preferto reduce the number of entities upon which trust is placed, and thispreference, in some cases, can be frustrated by use of external (e.g.,off-chain) datasets for things like data from financing statements froma government entity. Users may not trust the external data or that thedata was not subject to tampering while at rest or in flight, and manyexisting distributed ledger architectures are not lack technicalfeatures to mitigate this concern. Other challenges arise frominterfacing with a diverse set of data sources from differentgovernmental entities (e.g., possibly more than a thousand differentrecording offices), some of which may not expose an application programinterface by which remote systems can interrogate an authoritativedatabase of financing statements.

Another challenge lenders face arises from some of the very strengths ofsome forms of distributed ledger technology: low barriers to transactingand anonymity (or pseudonymity) in such transactions. Lenders often feara borrower will transfer the collateral to others. Lenders may havelittle effective recourse against a borrower who, after having granted asecurity interest, transfers the secured cryptographic asset to another,in some cases through tumblers or other mechanisms that make ittechnically difficult or impossible to track the asset or prevent itstransfer or foreclose on the asset. Thus, many lenders are resistant tolend against cryptocurrency because of concerns that it will simplydisappear after the loan is made due to the architecture andcomplexities of distributed ledger technology.

Another challenge to borrowing against cryptocurrency is one of trustbetween the borrow and lender. Contrary to popular perception, manyexisting computer systems touted as implementing distributed ledgertechnologies rely heavily on “off-chain” logic, or logic implemented incode running on computers exclusively under the control of a singleentity. There may be loan servicing decisions in which the borrower maynot trust the lender, or may not trust that future management of thelender will behave appropriately. Remedies in court can be uneconomic,due to the cost of lawsuits and delays (particularly when smalleramounts are in dispute), and insolvency law limits the ability ofparties to keep commitments that a trustee is allowed to waive. Theremay be decisions in the course of servicing a loan that are nottechnologically constrained by systems otherwise touted as implementingdistributed ledger technology, and mere legal or reputationalconstraints can be difficult to enforce. As a result, some borrowers mayfind these approaches unattractive.

Finally, to the extent other approaches are implemented with a“on-chain” logic, many types of distributed ledger technology are notwell suited to accommodate adjustments to the bargain the partiesoriginally struck. Examples of “on-chain” logic include smart contracts,which are programs run on a Byzantine-fault tolerant distributedcomputer system (like a blockchain computing platform), e.g., such thata threat actor interfering with one instance of program state on onecomputing device in the system does not necessarily prevent the largersystem from reaching the correct result of executing the program. Forexample, it may be (and often is) desirable for lenders to engage inforbearance, and not foreclose on an asset when the initial agreementwould otherwise permit the lender to acquire ownership of thecollateral. Many forms of smart contracts are immutable, which isdesirable for the reasons discussed in the previous paragraph, in thatthey can technologically enforce commitments, but such approaches canpresent challenges when the parties both wish to change the terms oftheir agreement. Thus, a lender may not wish to make a loan, or aborrower may not wish to secure a loan, if one or both parties believesthat the option to adjust the terms of the agreement is not feasiblewith on-chain logic.

A variety of techniques are described below to mitigate the technicalissues described above. Embodiments, however, are not limited toapproaches that solve all, or any, of these problems. Describedtechniques are independently useful, and some of these techniquesmitigate only a subset of the above-described issues. Indeed, someapproaches described below address other issues that will beself-evident to those of ordinary skill in the art. Accordingly, thedisclosure should not be read as limited to approaches that addressevery one of the problems described above, as the various approaches canbe used to address various subsets of problems with existing approaches.Further, for similar reasons, the preceding should not be read asdisclaiming any approach, as some techniques described below may be usedin combination with approaches characterized above as suffering fromdeficiencies.

Some embodiments monitor fluctuation in the value of cryptocurrencycollateral, for example, relative to a government-issued currency inwhich the obligation, like a loan, is denominated. In response tochanges, some embodiments adjust (e.g., automatically, for instance,without human intervention) an amount of cryptocurrency serving ascollateral. For example, some embodiments may automatically addcryptocurrency to a collateral account in response to determining thatthe value of the cryptocurrency has dropped by an amount sufficient tocause a loan-to-value ratio to fall below a threshold. In anotherexample, which may be used with the preceding example, some embodimentsmay instantiate offsetting smart contracts that neutralize (e.g., someor all of) the risk of fluctuations in the value of collateral, forexample, by instantiating another smart contract with a third-party thatcreates a put option to sell a corresponding amount of thecryptocurrency serving as collateral at a fixed price in the currencywith which the obligation is denominated at a fixed date in the future.

Some embodiments mitigate the risk of the cryptocurrency collateralbeing transferred by the borrower with a new account created in theborrower's name, without transferring ownership of the collateral insome cases. In some embodiments, the new account be may be a distributedledger account over which the borrower has diminished control, forinstance, in virtue of access credentials being withheld from theborrower (or other grantor of a security interest, like a guarantor).For example, some embodiments may create an account for the borrower ona distributed ledger, and that account may be characterized by a publiccryptographic key and a private cryptographic key of an asymmetricencryption key pair. A wallet address of that account may correspond tothe public key. And the private key may be required to transfercryptocurrency out of the account. In some embodiments, the privatecryptographic key of that controlled account may be withheld from theborrower to prevent the borrower from transferring the collateral untilthe secured obligation is satisfied. In some cases, the borrower mayretain title to that new cryptographic account, thereby retainingexposure to price fluctuations in the cryptocurrency and potentiallyavoiding what may be characterized as a sale of the asset, but withouthaving the ability to transfer cryptocurrency out of the new account. Insome embodiments, a smart contract may specify a wallet address to whichcryptocurrency is to be transferred when the obligation is satisfied,and in some cases that wallet address may be a wallet address controlledby the owner/borrower, or in some cases the wallet address may be thatof another controlled account of a junior lender against the asset witha subsequently granted security interest in the cryptocurrency. In somecases, multiple tiers of controlled accounts linked in this manner maybe used to implement a hierarchy of security interests in thecryptocurrency with technical measures in place to reduce the risk ofthe cryptocurrency being transferred away by the borrower.

Some embodiments may implement some or all of the loan-servicing logicof a lending agreement (e.g. a promissory note and grant of a securityinterest) on-chain, for instance, with a smart contract, therebypotentially mitigating concerns of borrowers regarding whether thelender will continue to be trustworthy even under future management.Some of these embodiments may further expose an application programinterface (API) of the smart contract to implement forbearance or otheradjustments to the terms of the agreement. In some embodiments, thesmart contract may be responsive to cryptographically signed inputs fromboth the borrower and the lender to instantiate a new smart contractwith new terms under forbearance, transfer the assets to a newcontrolled account, and close out the existing smart contract. Examplesinclude transferring the collateral from a first controlled account to asecond control account of the new newly instantiated smart contractencoded with terms of the agreed-upon forbearance.

Examples are described below with cryptocurrency as the collateral, butit should be emphasized that the present techniques are applicable to awide variety of virtual cryptographic assets. Other examples includeutility tokens and tokens representing other types of assets, such asrights in general intangibles under the UCC, real estate, chattel, orthe like. In some cases, these virtual cryptographic assets may bedenominated in cryptographic tokens, like satoshi, ether, and othernative cryptocurrencies, or non-native cryptocurrencies. In someembodiments, the tokens may be digital assets rendered rivalrous (e.g.,such that possession or consumption by one entity prevents consumptionor possession by another) by the properties of distributed ledgertechnology (for example, with blockchain technology), despite being indigital form. In some embodiments, the virtual cryptographic assets arefungible, like currency, or in some cases, the virtual cryptographicassets are nonfungible, like an ERC-721 (Ethereum request forcomments-721) tokens. Examples of nonfungible virtual cryptographicassets include things like CryptoKitties™ and, in some cases, thingslike accounts receivable and electronic chattel paper, where valuationdepends on the particulars of the transaction and rights represented bythe virtual cryptographic as set.

In some cases, embodiments described below adjust amounts of collateralresponsive to changes in relative value of various assets, like thecurrency in which an obligation is denominated (e.g., if the borrower isobligated to pay $100 in US dollars, US dollars is the currency in whichthe obligation is denominated) and a currency in which collateral isdenominated (or other virtual cryptographic assets).

The role of distributed ledger technology can take a variety of forms.In some cases, logical operations are implemented outside thedistributed ledger technology, for example, off-chain relative to ablockchain, while state of the loan (e.g., a loan amount, interest rate,payment due dates, debt covenants, payment histories, accrued interest,and the like), or portion thereof, may be persisted to a tamper-evidentdata structure, e.g., on-chain. For example, some or all of the loanparameters may be stored in a blockchain. In some cases, loan parametersmay be rendered tamper evident without storing the parameters themselvesin a tamper-evident data structure, for example, by writing acryptographic hash (or output of some other one-way function responsiveto the parameters as input) of the loan parameters to the tamper-evidentdata structure.

A variety of different tamper-evident data structures are contemplated.In some cases, a directed acyclic graph of cryptographic hash pointersmay be used to render loan parameters temper evident, for example, bystoring those loan parameters in nodes of the graph or storingcryptographic hash values thereof in nodes of the graph (or both). Insome cases, various other cryptographic accumulators may be used as aone-way membership function to render loan state tamper evident. In somecases, these data structures may be implemented with a one-way function,like a cryptographic hash function, that it is relatively easy tocompute given an input, but it is relatively difficult to invert todetermine the input given an output. Easy and hard may be measured withreference to computational complexity theory, for example, with a “hard”computation being more than six orders of magnitude more resourceintensive in memory or time complexity than an “easy” computation.

In some cases, the one-way function is a cryptographic hash functionthat maps an input of arbitrary size to a fixed length output. Thecryptographic hash function may be deterministic, relatively easy tocompute, computationally infeasible (e.g., hard) to invert,computationally infeasible to determine hash collisions (that is, findcases where two different inputs produce the same output), and arelatively small edit distance to an input (e.g., flipping a bit) mayproduce an output that it appears uncorrelated with the hash value ofthe unedited input. In some cases, the cryptographic hash function maybe implemented with repeated application of the Merkle-Damgårdconstruction. Examples of cryptographic hash functions include MD5,SHA-1, SHA-2, BLADE2, BLAKE3, RIPEMD-160, Whirlpool, and the like. Theseor other one-way functions may be repeatedly applied to the combinationof updates and one-way function outputs characterizing thetamper-evident data structure, e.g., as the data structure evolves torender changes to that data structure tamper evident.

For example, it may be computationally infeasible for a threat actor totamper with a committed value to the data structure in a way that doesnot make the data structure internally inconsistent due to theproperties of the one-way function. The value tampered with may beinconsistent with downstream outputs of the one-way function in the datastructure, and it may be computationally infeasible to select the valuetampered with to compute a hash collision that would leave the datastructure internally consistent. Other processes may detect suchinconsistency by recomputing the one-way function and detecting that theresult does not match that presently recorded output, signaling that thedata structure has been subject to tampering, and in some cases,indicating which value has been subject to tampering. Such one-wayfunctions (or other one-way functions, like asymmetric encryptionfunctions) may further be used in cryptographic signatures applied toinputs described below to render those inputs tamper evident as well, insome cases.

FIG. 1 illustrates an example of a computing environment 10 in whichsome embodiments may be implemented. Other examples are described belowwith reference to FIGS. 4, 5, and 6 , some versions of which areconsistent with the embodiments characterized by FIG. 1 . In some cases,these implementations may execute processes like those described belowwith reference to FIGS. 2 and 3 to create and service securedobligations using distributed ledger technology.

In some embodiments, the computing environment 10 is a distributedcomputing environment involving computing devices operated by differententities having different roles and operations described below. In someembodiments, the environment 10 includes a loan-servicer computer system12, a borrower computing device 14, and a distributed ledger 16, whichmay all communicate via the internet 18. In some cases, separatecomputing devices (e.g., operated by different entities) may originateand service loans, or in some cases a single device (or system made ofone or more devices) may fill this role. A single borrower computingdevice 14 is shown, but embodiments are consistent with substantiallylarger populations of borrower computing devices, for example, numberingin the hundreds, thousands, millions, or more. Similarly, theillustrated components of FIG. 1 may be geographically distributed, forexample, over the entire United States or world.

The illustrated systems may include one or more computing devices, forexample, a plurality of servers, and the devices may each include one ormore processors, memory, network interfaces, and various other forms ofinput and output, like touchscreens, microphones, speakers, and thelike. In some cases, these computing devices may include a tangible,non-transitory, machine-readable medium, such as memory (e.g.,persistent or dynamic), storing program code with which thefunctionality described herein is implemented when executed by theprocessors. Notwithstanding use of the singular term “medium,” thatprogram code may be distributed among multiple computing devices, forexample, with different instructions in memory of different computingdevices serving different roles. Similarly, those instructions may bestored in memory of a computing device that does not execute theinstructions, for example, in memory hosted in a public or private coderepository, or a repository of native applications hosted by, forexample, a provider of an operating system for downloads to computingdevices.

In some embodiments, the loan-servicer system 12 cooperates with thedistributed ledger 16 to create and service loans. Servicing securedloans (or other secured obligations) may include calculating accruedinterest, providing updates to a borrower or lender about state of theloan, calculating accumulated payments, determining when the loan is indefault, determining whether to grant forbearance, and determining whena loan obligation has been satisfied and a security interest can bereleased (and effectuating the same). In some cases, the loan-servicersystem 12 additionally implements techniques to perfect securityinterests in collateral (or otherwise mitigate risk of otherencumbrances on collateral) and adjusts amounts of collateral inaccordance with the techniques described below. In some embodiments, theloan-servicer system 12 may operate in the context of a paymentprocessor computer system like that described below with reference toFIG. 6 . In some embodiments, the loan-servicer system 12 is implementedwith a monolithic architecture, running on a single computing device,like a server, or in some cases, a distributed computing architecturemay be used, such as a microservices architecture, lambdas, variousservice-oriented architectures, and the like. Or some embodiments mayoperate entirely on-chain, without a loan-servicer system 12, which isnot to suggest that any other described feature may not also be omittedin some embodiments.

In some embodiments, the borrower computing device 14 communicates withthe loan-servicer system 12 to instantiate a loan, make payments, viewupdates about the loan, request forbearance, and the like. The borrowercomputing device 14 may, for example, be various forms of computingdevices operated by end users, examples including laptops, desktops,smart phones, wearable computing devices, set-top boxes, in-storekiosks, and the like. The borrower computing device 14 may execute anapplication by which information is presented to users and inputs arereceived from users, examples including a web browser or native mobileapplication or other special purpose application, each of which mayexecute with an operating environment operating system of the device 14.

In some cases, the borrower computing device may be operated by a userwho, by operation of a client application (like a browser or nativeapplication) supplies credentials, like a username and proof ofpossession of some knowledge-factor credential, like a hash of apassword, to authenticate themselves to the loan-servicer system 12. Insome cases, the user's identity indicated by such credentials may beassociated with a broader suite of services provided by an operator ofthe system 12, for example, payment processing services like thosedescribed below. Or in some cases, the extent of the relationshipbetween the identified user and the entity operating the system 12 maybe a single loan.

In some embodiments, the distributed ledger 16 may serve various roles,depending upon the implementation, as discussed above. In someembodiments, the distributed ledger 16 may be a public or a private,permissioned or permissionless, implementation of distributed ledgertechnology, like a public or private blockchain. In some embodiments,state of the distributed ledger 16 may be replicated among a pluralityof different computing devices controlled by a plurality of differententities, and a consensus algorithm may be executed to determine stateof the distributed ledger, such that modifications to the distributedledger cannot be made unless more than a threshold amount of theparticipating entities reach consensus. Examples of such consensusalgorithms include Paxos, Raft, HotStuff, Tendermint, Casper, andvarious other Byzantime fault-tolerant consensus protocols. In somecases, various entities (e.g., participating computing devices, or peerapplication instances executing thereon and serving as peer nodes in aByzantime fault-tolerant network) may serve different roles in consensusprotocols. For example, some entities may be elected as leaders andthose entities may emit a periodic heartbeat signal to other peer nodes.In some embodiments, peer nodes may elect a new leader responsive to theabsence of such a heartbeat signal for more than a threshold duration oftime to afford resiliency to the failure of any one peer node. In somecases, peer nodes may determine consensus regarding state by majorityvote, e.g., as computed by leaders based on votes from other peer nodes.

In some embodiments, peer nodes participating in consensusdeterminations may be required to demonstrate the right to do so beforebeing permitted by other peer nodes to participate. In some cases, peernodes may be required to demonstrate that they have consumed some scarceresource, for example, by executing a proof-of-work or proof-of-storageroutine. In some embodiments, proof-of-work may be implemented bycomputing a partial hash collision. Some embodiments may require peernodes to compute an input to a hash function that produces an outputwith a specified number of leading or trailing zeros, for example, and adesignated suffix or prefix that varies between proofs. In some cases,peer nodes may be required to stake cryptocurrency as a condition ofparticipating in consensus determinations, for example, without havingto execute proof-of-work or proof-of-storage. Some embodiments may beimplemented without requiring any of these approaches (which is not tosuggest that other described features are limiting), for example, inpermissioned private blockchain implementations in which peer nodes areauthenticated by demonstrating possession of credentials to other peernodes, for instance, by transmitting a cryptographic hash of a passwordor cryptographically signing a challenge (e.g., a string with adesignated amount of entropy, like a random value of 256 bits or more)with a private key corresponding to a public key to which the challengewas addressed. Other peer nodes may verify these signatures as acondition of counting votes from the signing peer nodes.

In some embodiments, peer nodes may be addressed and authenticated basedon public key infrastructure. In some cases, peer computing nodes withwhich the distributed ledger is implemented may each have an addresscorresponding to a private cryptographic key and public cryptographickey generated with an asymmetric encryption algorithm, each peer nodebeing uniquely identified by a different key pair in some embodiments.Examples include ElGamal, Diffie-Hellman, RSA, elliptic curve,lattice-based encryption techniques, and the like (which are allrelevant to other references to asymmetric encryption herein). In somecases, the address (at the application layer) of peer nodes is thepublic key, or the address may be deterministically computed based onthe public key. In some embodiments, application layer addresses may beimplemented with techniques like distributed hash tables, for example,with Kademlia, Chord, Tapestry, Pastry, or the like. Some embodimentsmay discover peer nodes with various forms of orchestration tooling ordomain name services.

In some embodiments, the distributed ledger 16 may, in addition torendering some state of the loans or all state of the loans tamperevident, execute logic of the loan agreements. Examples includecalculating accrued interest, determining whether payments are late ordebt covenants have been breached, determining accumulated paymentamounts, detecting default, implementing forbearance, determining whencollateral fails to satisfy loan-to-value thresholds, and determiningwhen a loan obligation has been satisfied and a security interest can bereleased. In some cases, some or all of these logical operations may beimplemented in a decentralized manner, for example, with ablockchain-based computing platform like Ethereum™, Cosmos™, Cardano™EOS™, or Hyperledger™. In some cases, the decentralized computingplatform may persist state to the above-describe tamper-evident datastructures and the computing nodes may use verifiable computingtechniques to execute scripts in a way that does not require all of thecomputing devices be trusted to faithfully execute the logic of thescript. Examples include smart contracts implemented on the precedingplatforms, for example, encoded in Solidity or Java or interpreted to anative bytecode.

In some embodiments, the scripts (or other types of programs) may beassigned an address on the distributed ledger (in some cases, in thesame address space as wallet addresses), and functionality of thescripts may be invoked by transacting with that address withtransactions including arguments of the script, like variables, andother parameters of called functions. Upon being invoked, the scriptsmay be executed in a replicated fashion among a subset or all of thepeer nodes with which the distributed ledger 16 is implemented, and thepeer nodes may arrive at a consensus as to the result of executing thescript in a manner like that described above with a consensus protocol.As a result, in some cases, the entities operating the peer nodes neednot be trusted (e.g., to not interfere with executing of their localcopy of the script by, for instance, tampering with its code or localstate), as long as malicious peer nodes constitute less than a thresholdamount of the participants in the network of peers determining consensus(e.g., less than half or less than a third). In some embodiments, toexpedite operations, sharding may be used, and a subset of peer nodesmay concurrently and redundantly execute the script to reach consensus.In some cases, those subsets may be selected, for example, randomly, forinstance, in sharded some blockchain-based computing platforms. Or insome cases, every peer node in the computing platform may execute asmart contract redundantly upon invocation of the smart contract.

In some cases, logic that is related to servicing the loan may beexecuted by either the loan-servicer system 12 or a Byzantinefault-tolerant decentralized computing platform, like one implementingthe distributed ledger 16. All permutations of allocation of logicbetween these two architectures are contemplated. For example, somelogical operations may be performed on the system 12 and others on thesystem implementing the distributed ledger 16, all logical operationsmay be performed in the system 12, or all logical operations may beperformed on a decentralized computing platform implementing thedistributed ledger 16. Similarly, various permutations of allocation ofstate between these two architectures are contemplated, in some cases,with only a single field being rendered tamper evident by a distributedledger.

In some cases, peer nodes implementing the distributed ledger 16 may begeographically distributed and may communicate via the internet 18. Insome embodiments, the distributed ledger 16 may have a federatedarchitecture, like a permissioned distributed ledger in which some ofthe peer nodes have more elevated authority relative to others. Examplesinclude some implementations of Libra™ and some implementations ofCardano™.

Some functionality of the loan-servicer system 12 and the distributedledger 16 may be implemented with processes like those described belowwith reference to FIGS. 2 and 3 .

In some embodiments, loans may be serviced with a process 20 illustratedby FIG. 2 . The functionality of this process and the otherfunctionality described herein may be implemented with program codestored on computer-readable media, like a tangible, non-transitory,machine-readable medium. The described operations, here, and elsewhere,may be executed in a different order from that described, someoperations may be repeated, some operations may be executedconcurrently, some operations may be executed serially as depicted,operations may be omitted, and additional operations may be inserted,none of which is to suggest that any other feature described elsewhereherein is limiting. In some cases, multiple instances of the describedprocesses may execute concurrently in multiple concurrent sessions, likemore than 10, 100, or 1,000 concurrent sessions. In some embodiments, asdiscussed above, various steps of the process 20 may be executed ondifferent computing devices, for instance, some or all may be performedby the loan-servicer system 12, the computer system implementing thedistributed ledger 16, or both.

In some embodiments, the process 20 includes receiving a request tocreate a secured loan (or various other forms of secured obligation), asindicated by block 22. Examples include purchase money loans, cashloans, payday loans, margin accounts, and lending against various formsof general intangibles, like those discussed above. In some embodiments,the request may be received by the system 12 described above from theborrower computing device 14, for instance, from a native application orweb browser executing thereon and presenting an interface, such as oneserved by the loan-servicer system 12 to receive and provide loanparameters to the system 12. Or in some cases, the request may bereceived by a smart contract executing on a computer system implementingthe distributed ledger 16. Or in some cases, a request may be receivedby the system 12, and that request may be transformed into a requestreceived by the computer system implementing the distributed ledger 16.In some embodiments, the request may specify the loan parametersdescribed above or various subsets thereof.

In some embodiments, the request is a transaction to instantiate a smartcontract implementing a loan. In some embodiments, the computer systemhosting the distributed ledger 16 may instantiate the smart contract,assigned the smart contract an address in an address space of thecorresponding computing platform (which may be an application-layeraddress that is distinct from a network layer address space), and recordthe instantiation and initial state in a tamper-evident data structurelike those described above. In some embodiments, instantiation mayinclude executing steps 24 through 28 described below and scheduling orregistering to receive events that cause execution of other operationsdescribed with reference to FIG. 2 , for instance, by registeringcallback functions with a time oracle, a price oracle, an interest rateoracle, or a payments oracle, like those described below with referenceto FIG. 4 . In some cases, registering a callback function may includeidentifying the address of the instantiated smart contract andindicating arguments and name of the function to be supplied in the callback.

Some embodiments may create a controlled wallet account for theborrower, as indicated by block 24. A controlled wallet account is anaccount of the distributed ledger 16 or another distributed ledger inwhich the borrower's ability to transfer assets (or at least the assetsdesignated as collateral) out of the account is limited or eliminatedwithout the consent of the lender. Examples include a Bitcoin, Ethereum,or Hyperledger account for which the borrower is not provided theprivate key (or recovery passphrase or other knowledge factorcredentials) required to transfer assets out of the account. (In somecases, a controlled wallet account can be transformed into anuncontrolled wallet account by providing this information to theborrower.) Or in some cases, a distributed ledger may support operationsby which a virtual cryptographic asset is designated as non-transferablewithout a lender providing consent, e.g., with a cryptographicallysigned message to that effect, and some embodiments may only constrain asubset of assets in an account, an arrangement also consistent with theterm “controlled wallet account,” which may also be referred to as a“controlled account.” Similarly, in some cases, a distributed ledger maysupport operations by which downstream parties acquiring assets do sosubject to on-chain foreclosure of the asset, e.g., with on-chain noticeprovided to the party, and by operation of smart contract, anarrangement also consistent with the term “controlled wallet account,”as the control runs with the asset after transfer from the account. Theterm “wallet account” refers to an account that, given the propercredentials, is accessible via, for example, a wallet application, butdoes not require a wallet client application to be used.

In some cases, creating a wallet account can be relativelycomputationally expensive and can be particularly resource intensivewhen done on-chain, in part due to replicated instances of theoperations being run on a plurality (and in some cases, all) peer nodes.In some cases, as a result, transaction costs, e.g., in the form of anative cryptocurrency consumed when computing smart contracts, can berelatively high. To make this operation less resource intensive, someembodiments may create the wallet account off-chain, e.g., with theloan-servicer system 12 computing the corresponding cryptographic keypair, and then some or all of the resulting credentials and addressesmay be written to the smart contract before deployment. Or someembodiments may perform these operations on-chain, e.g., by executing anasymmetric encryption protocol to create the account in a smartcontrast.

In some cases, creating the controlled wallet account may includecommunicating an account address to the borrower's computing device, forexample, in the form of a QR code (or other optically scannable code) orstring of characters. Or in some embodiments, this information may bewithheld from the borrower. In some embodiments, the controlled walletaccount may be deemed to be owned by the borrower in memory of theloan-servicer system 12, for example, as indicated in agreements betweenthe borrower and the lender, with the lender having a security interestin assets transferred to the controlled wallet account. In some cases, apre-existing controlled wallet account may be re-used, an arrangementconsistent with use of the term “create” in this context.

Reference to accounts should not be read to suggest that the presenttechniques are limited to blockchain computing platforms having anaccount/balance model. Some embodiments may also or alternativelyimplement a UTXO (unspent transaction output) model. Both of which areconsistent with use of the term “account.” A wallet account may have aprivate cryptographic key and a corresponding public cryptographic key,such as one generated with the above-described examples of asymmetricencryption protocols. Assets may be transferred to the wallet account bytransferring them to an address that is or corresponds (e.g.,deterministically in a one-to-one relationship) to the publiccryptographic key. In some embodiments, the computer system implementingthe distributed ledger 16 may require that a transaction transferringassets out of the wallet account include or be associated withinformation demonstrating possession of the private cryptographic key,for example, a cryptographic hash thereof or a cryptographically signedchallenge that is signed with the private cryptographic keycorresponding to the public address of the wallet account.

In some cases, the controlled wallet account may be distinct fromanother wallet account of the borrower, such as another wallet accountin which the cryptocurrency or other virtual cryptographic asset thatwill serve as collateral resides. In some embodiments, the borrower mayhave a wallet account that is uncontrolled from the perspective of thelender and, upon execution of block 24, a wallet account that iscontrolled from the perspective of the lender. In some cases, theborrower may have access to the private cryptographic key of theuncontrolled wallet account to transfer assets from that account, e.g.,in virtue of such a key being stored by a client wallet applicationexecuting on the borrow computing device and storing the key in memoryof that device.

In some embodiments, the process 20 includes transferring cryptocurrencyto the controlled wallet account to serve as collateral, as indicated byblock 26. The collateral may be collateral to the loan created in block22. In some embodiments, each created loan may have a unique identifier,such as the address of the smart contract with which its created, oranother identifier in some other namespace, like that of theloan-servicer system 12 described above. In some cases, thecryptocurrency is transferred responsive to instructions from theborrower's computing device (e.g., from a wallet client application) bythe computer system implementing the distributed ledger 16 withoutfurther operation of a smart contract creating loan. Or in someembodiments, as part of creating the loan, the borrower computing devicemay supply the information needed to effectuate the transfer byoperation of the smart contract, for instance, supplying the valuedemonstrating possession of the private cryptographic key of theuncontrolled wallet account from which the collateral is to betransferred to the controlled wallet account and an address of theuncontrolled wallet account from which the virtual cryptographic assets,like cryptocurrency, are to be transferred. In some cases, for instancewhere the collateral is a nonfungible asset, the creation of the loanmay include identifying those tokens with unique identifiers thatdistinguish them from other instances of that type of token. For sometypes of nonfungible assets, the smart contract may distinguish betweeninstances of nonfungible virtual cryptographic assets when transferringto the controlled wallet account to select the appropriate virtualcryptographic asset to transfer that accords with the parties' intent,for instance, as expressed in the request to create the loan. Therequest to create the loan may refer to a loan (or other obligation)that already exists in a legal sense or a loan that does not yet exist,both consistent with the term “create,” as both create records by whicha loan is documented and managed in the systems described herein.Similarly, obtaining parameters of an obligation can be performed bothfor a pre-existing obligation and one for an agreement that is yet to beconsummated. Creating refers to creating the corresponding records(executable or otherwise) of such an obligation.

In some cases, a different entity from the lender or the entityoperating the loan-servicer system 12 may control the controlled walletaccount. Examples include a bailee or an escrow agent. Further, in somecases, control may depend on possession of multiple credentialscorresponding to multiple entities, e.g., in an escrow arrangement inwhich both the borrower and lender must consent to a transfer withcryptographically signed messages. In each of these examples, herein,the collateral is still said to be under the control of the entityoperating the loan-servicer system 12, e.g., even if control isdelegated or shared.

In some embodiments, the described requests and messages may be a singletransmission, or the conveyed information may be sent in a sequence oftransmissions as part of a session, for example, with interveningback-and-forth, all consistent with use of the singular term “request”and similar terms in singular form.

Some embodiments may determine whether a specified amount ofcryptocurrency designated as collateral is present to be transferred aspart of the transfer operation 26. Upon determining that the thresholdamount is not present to be transferred, some embodiments may ceaseoperation and issue an alert and, in some cases, transfer thecryptocurrency back to the uncontrolled wallet account and preventdisbursement of loan principal, as the specified collateral is notpresent. Or some embodiments may cause the borrow computing device topresent a user interface by which the user may intervene to supplyadditional collateral or identify other addresses. In some cases, a usermay specify a plurality of different uncontrolled wallet accounts fromwhich funds are to be transferred, in some cases specifying how muchcryptocurrency to transfer from each of the different wallet accounts,for example, as part of the request to create a loan in operation 22,and some embodiments may execute operation 26 a plurality of differenttimes for each of those different uncontrolled wallet accounts.

Upon determining that the specified collateral has been transferred tothe controlled wallet account in operation 26, some embodiments maydisperse loan principal, as indicated by block 28. In some cases, thismay include an ACH transfer, effectuating the mailing of a check, or atransfer of some other form of cryptocurrency, like a stable coin (e.g.,a cryptocurrency pegged to a government-issued currency), to a walletaccount address designated by the borrower. In some cases, this walletaccount address may be specified in the request to create a loan, alongwith the amount of loan principal to be provided.

Some embodiments may subsequently perform operations described below toservice the loan over the life of the loan. In some cases, some of theseoperations may be initiated responsive to events, for example, uponinvocation of the above-described registered callback functions, likeresponsive to a price change in the collateral as an event, responsiveto a threshold duration of time elapsing, responsive to a specified timeoccurring, responsive to a payment, or the like. In some embodiments,some of these operations may be executed repeatedly asynchronously,periodically or intermittently, throughout the life of the loan, untilthe security interest is released or the collateral is foreclosed upon.In some cases, the various described oracles may be polled with periodicqueries by some embodiments to obtain such events.

Some embodiments may determine whether to update loan state, asindicated by block 30. In some cases, this determination may be made,for example, by the loan-servicer system 12 that runs area rules enginewith an infinite loop that cycles, e.g., every few seconds, hours, ordays, and determines in each cycle whether to update loan state of eachloan in the system based on various criteria (e.g., whether a payment isdue or a duration of time has elapsed since a previous update). Upondetermining that it is not time to update loan state, embodiments mayreturn until another operation is triggered, as indicated in FIG. 2 .Upon determining that it is time to update loan state, for example,responsive to a price change query, a time that has lapsed, or anotherevent that has occurred, some embodiments may proceed to update loanstate, as indicated in block 34, e.g., by executing the process of FIG.3 .

In some embodiments, updating loan state may include the operationsdescribed below with reference to FIG. 3 . Examples include calculatinginterest payments, determining whether collateral satisfiesloan-to-value ratios, computing accrued interest, calculatingaccumulated payments, determining whether the loan is in default, ordetermining whether the loan obligation has been satisfied.

Some embodiments determine whether a payment has been received, asindicated by block 32. In some embodiments, this may be one type ofevent to which the determination of block 30 is responsive to updateloan state. The determination of whether a payment has been received maybe made by querying a database in which payment history is stored orresponsive to an event, for instance, one that invokes a registeredcallback function like that described above that prompts a loan update.Again, receiving a payment may result in the updating of the loanupdate, as indicated by block 34, e.g., by executing the process of FIG.3 .

Some embodiments may include determining whether to release a portion ofan entirety of the security interest, as indicated by block 36. In somecases, this may be part of updating loan state 34, e.g., by executingthe process of FIG. 3 . Some embodiments may determine whether the totalof the accumulated payments (e.g., monthly payments over a year orlonger, or a one-time payment) is greater than or equal to a thresholdvalue, like a value of the secured obligation, which in some cases, mayinclude the loan principal and interest and fees. In some cases,interest may be compounded or non-compounded interest may be applied.

Upon determining to not release the security interest, some embodimentsmay continue the above-described operations, as illustrated.

Upon determining to release the security interest in block 36, someembodiments may proceed to transfer the cryptocurrency to anuncontrolled account of the borrower (or guarantor if different), asindicated by block 38. In some embodiments, this transfer may beeffectuated without moving the cryptocurrency between wallet accounts,by transforming the controlled wallet account into an uncontrolledwallet account. Such transformation may be effectuated by disclosing theprivate cryptographic key or other knowledge factor credentials to theborrower for the controlled wallet account to transform that accountinto an uncontrolled wallet account, an arrangement also consistent withuse of the term “transfer.” Or some embodiments may effectuate atransfer to a wallet account specified by the borrower in the request tocreate the loan or, if different, to the wallet account from which thefunds were transferred into the controlled wallet account. The term“transfer” is not limited to operations of a smart contract. The term'sreferents include operations by a smart contract to transfercryptocurrency and actions that invoke, directly or indirectly, suchoperations by a smart contract. A party can transfer cryptocurrency byexecuting the smart contract when effectuating a move of cryptocurrencybetween accounts or by causing such a transfer another way, for instanceby calling the smart contract to request such a move (without executingthe smart contract themselves). The transfer may include updating arecord in a distributed ledger to reflect the change, as discussed belowwith reference to FIG. 5 .

Additionally or alternatively to perfecting by control, some embodimentsmay perfect the security interest by filing a financing statement, suchas a UCC-1 form, with the borrower's home state, such as the state inwhich a business entity is formed or operates. Some embodiments mayrelease a security interest by filing a release as well. In some cases,the filing may be via an application program interface exposed by agovernmental entity with which such filings are made. Some embodimentsmay further query these records via such an API before creating a loanand determine, based on a response, whether the proposed collateral isencumbered, in which case some embodiments may determine to not createthe loan.

In some embodiments, various rights that accompany the collateral may beallocated by operation of the smart contract or agreement between theparties. Examples include staking rights. In some cases, the lender mayexercise the right to stake the cryptocurrency in the controlled accountof the borrower and retain the right to transfer rewards for staking toan account of the lender, or in some cases, staking may be performed onbehalf of the borrower, and the proceeds may be transferred to thecontrolled account or an uncontrolled account of the borrower. Someembodiments may automatically stake collateral and allocate rewards fordoing so. Similarly, governing rights on the computing systemimplementing the distributed ledger 16 may be accorded by agreement ofthe parties and, in some cases, encoded in the smart contract. Examplesinclude voting rights on changes to operation of the distributed ledger16. In some cases, the these rights may be reserved for the lender, todis-incentivize majority attacks in which borrowers attempt to enhancetheir voting positions temporarily by offering up their cryptocurrencyas collateral and using the loan proceeds to purchase additionalcryptocurrency, in some cases repeating the process an arbitrary numberof times to amplify their voting power to, for example, damage acryptocurrency platform in which they have previously taken a shortposition, thereby, potentially leaving the lender with impaired orworthless collateral.

In some cases, the public (off-chain) identity of borrowers or lendersmaybe attested to by an identity oracle. Such systems maycryptographically sign statements attesting to the identity of theparties responsive to various controls in place, e.g., inspectingauthenticating documents, or a history of previous engagements.

Use of the singular term “smart contract” should be understood asencompassing implementations in which functionality is distributed amongmultiple scripts, for example, in a call graph in which program code isorganized into different modules, which may themselves each bedesignated as distinct smart contracts having distinct addresses on ablockchain computing platform. These call-graph-based implementationsare consistent with use of the singular term “smart contract.”

Further, relying on antecedents should not be read to exclude evolutionof the thing referenced over time, between references. For example,reference to “a smart contract” followed by reference to “the smartcontract” should be read as encompassing implementations in whichdifferent smart contracts in the same call graph respectively correspondto the antecedent and the subsequent reference, i.e., that using thedefinite article. Similarly, reference to a unit of cryptocurrency (orother fungible virtual cryptographic asset) followed by reference to“the” cryptocurrency are consistent both with scenarios in which thesame units of cryptocurrency are being referenced and scenarios wherethere has been turnover in the cryptographic assets being referenced.For example, adding a bitcoin to an account referenced as “a bitcoin,”replacing that bitcoin with another, and then referencing “the bitcoin”should be understood to encompass this scenario, in which the bitcoin isdifferent from that initially added. In another example, reference to“an obligation” or “a loan” followed by reference to “the obligation” or“the loan” is consistent with scenarios in which the amount ofoutstanding obligation or loan balance has changed between references,e.g., creating a loan, making a payment against the loan, and thendetermining whether the loan has sufficient collateral includesscenarios where the loan balance for the determination is different fromthat present when the loan is created. Similar principles should beapplied to terms relating to other referents that evolve over time.

FIG. 3 illustrates an example of a process 40 by which loan state may beupdated. As with the other functionality described herein, theillustrated operations may be implemented by operation of the smartcontract or off-chain, for example, with logic implemented by theloan-servicer system 12 described above, or in any permutations ofcombinations thereof.

In some embodiments, the process 40 includes verifying any payments thatmay have been made, as indicated by block 42. In some embodiments,payments may be made on-chain, for example, by transferring acryptocurrency in which the loan is denominated into a payment accountof the lender. In some embodiments, a payment account unique to the loanor unique to the borrower may be created, or a single shared paymentaccount may be used across all loans for a given lender. In some cases,transactions making payments corresponding to a loan may be accompaniedby identifiers of those loans, like an address of a smart contractencoding the loan, for instance, in comment fields, so that payments maybe mapped to the appropriate loan.

In some cases, payments may be made off-chain, for example, into a bankaccount of the lender, such as one operated by, or with access rightsaccorded to, the entity operative operating the loan-servicer system 12.In some cases, this entity or another entity may operate a paymentsoracle like that described below, which may generate events, respond toqueries, or execute callback functions that inform a smart contract of apayment event and the attributes thereof, like the date and amount. Insome cases, these payment attributes may be cryptographically signedwith a private key corresponding to a public key of the payments oracle,and verifying payment may include ensuring that the payment informationhas not been tampered with by verifying that the cryptographicsignature, for instance, that the public key corresponds and that thesignature demonstrate possession of a private key, or in some cases thatthe payment information hashes to a cryptographic hash included with thesignature. In some cases, if any of these checks do not correspond, someembodiments may decline to credit the payment and log an alarm, or someother error message may be logged, which may prompt human review.

Some embodiments may further compute accrued interest, as indicated byblock 44. Again this, like the other operations may be performedon-chain or off-chain. In some embodiments, interest may be compoundinterest. In some cases, a current loan state may indicate a time atwhich the current loan state was computed, and computing the accruedinterest may include computing a delta in time between the current timeand that time and calculating an amount of interest based on theinterest rate stored on chain and associated with the loan, like as aparameter of the smart contract.

Some embodiments may compute a loan balance, as indicated by block 46,which again may be implemented on-chain or off-chain. In some cases,computing the loan balance may include summing payments and accrued feesand computed interest. In some embodiments, the computed loan balancemay be persisted to the distributed ledger 16 described above, orotherwise rendered tamper evident, for instance, by storing the valueoff chain and writing a cryptographic hash thereof on-chain.

Some embodiments may verify a value of the collateral, for instance, inthe controlled wallet account discussed above, as indicated by block 48.In some embodiments, verifying the value of the collateral may includequerying or receiving an event or invocation of a callback function froma payments oracle, like those discussed below. In some embodiments,received information may again be cryptographically signed, and thetypes of verification applied to the payment may also be applied toprice information to, for example, prevent or impair attacks in whichfraudulent price information is injected into the system by threatactors. For example, some embodiments may verify that the priceinformation, like price of the cryptocurrency in the collateral account,is from an entity that has demonstrated access to a privatecryptographic key corresponding to the public cryptographic key (orother corresponding identifier) of the entity expected to provide theprice information. In some cases, the price oracle may be an exchange inwhich the cryptocurrency in the collateral account is publicly traded,like the Coinbase™ oracle accessed via the corresponding API.

In some cases, time information may also be provided by a time oracle,for instance, via signed attestations as to the current time. In someembodiments the time information may also be subject to verificationlike that described for price information and payment information, toverify that the time information (e.g., the current time) is beingobtained from a trusted party.

Some embodiments may determine whether the value of the collateral isgreater than or equal to a loan-to-value ratio, as specified in block50. In some embodiments, when creating the loan, loan parameters mayspecify a loan-to-value ratio of the collateral in terms of a currencyin which the loan is denominated, like US dollars or a stable coin. Someembodiments may multiply the collateral by the price information anddetermine whether the result satisfies a threshold corresponding theloan-to-value ratio, for example, is greater than (or is greater than orequal to) the threshold, both being examples of satisfying a thresholdcriterion. Some embodiments may divide the product of the collateral andthe price information by the loan principal or an amount outstanding onthe loan balance to compute a loan-to-value ratio and determine whetherthat value satisfies the threshold loan-to-value ratio. Some embodimentsmay adjust the loan-to-value ratio based on various events or otherdata, e.g., some embodiments may compute a credit-worthiness score(e.g., of the transaction or of a party to the transaction) based onother behavior, for instance other transactions involving the computingenvironment of FIG. 6 (e.g., direct deposits, reoccurring payments,etc.). In some cases, the loan-to-value threshold may be adjusted tospecify less collateral responsive to such signals indicating greatercredit worthiness.

Upon determining that the threshold is not satisfied, for instance, thatthe collateral does not have sufficient value, some embodiments mayproceed to block 52. Some embodiments may then transfer additionalcryptocurrency into the controlled wallet account, as indicated by block52. In some embodiments, this transfer may be effectuated with thetechniques described above with reference to block 26. In someembodiments, a window of time may be designated in which the transfermust be implemented at the instruction of the borrower, for instance,with a corresponding callback function being registered to effectuate acheck at the corresponding time, or some embodiments may automaticallytransfer the additional cryptocurrency into the controlled walletaccount using information supplied by the borrower. Some embodiments maythen proceed to block 54 in some cases without regard to the result ofblock 50.

Some embodiments may determine whether the loan is currently in adefault state, as indicated by block 54. In some cases, default mayoccur because additional cryptocurrency is not available to satisfy thedetermination of block 50. Other criteria for default may include adetermination of whether a payment has not been received by a specifiedtime or other debt covenants have not been met.

In some embodiments, interest rates may be variable, and someembodiments may access an interest rate oracle to obtain a currentinterest rate by various measures. In some embodiments, the interestrate oracle may provide a cryptographically signed variable interestrate, such as the secured overnight finance rate (SOFR) or the Londoninterbank overnight rate (LIBOR), and in some cases, loan parameters mayspecify how to calculate an adjustable interest rate, for instance, bycausing a smart contract to add a constant to these reference rates.

Upon determining that the loan is not in default, some embodiments ofthe process 40 may terminate, until invoked again, for instance, in thecontext of block 34 in FIG. 2 .

Upon determining that the loan is in default in step 54, someembodiments may proceed to determine whether forbearance has beenrequested, as indicated by block 56. In some embodiments, the step maybe reached without regard to whether default has already occurred in theflow of process 40, which is not to suggest that other operations arelimited to the sequence with which they are currently presented. In somecases, determining whether forbearance has been requested may includedetermining whether a forbearance function of the loan's smart contracthas been invoked with parameters indicating the consent of both thelender and the borrower. In some cases, such consent may be indicated bycryptographically signing a message, like a challenge or the requestitself with a private cryptographic key corresponding to a public keythat correspond to an identifier of each party. Determining whetherforbearance is requested may include verifying these consents (e.g.,that the cryptographic signature demonstrates possession of the correctprivate keys, in some cases, based on the public keys and without accessto the private keys being afforded to the process performing theverification).

Upon determining that forbearance has been requested, in someembodiments, the smart contract encoding the loan (or correspondingoff-chain logic, e.g., executed by the loan-servicer system 12) mayexecute a subroutine to implement the forbearance. In some embodiments,the forbearance subroutine creates a new loan using techniques likethose described above with revised terms indicated in new loanparameters (e.g., supplied in the request for forbearance from computingdevices of the parties). In some cases, this may include instantiatingthe new loan (e.g., a new smart contract) with revised terms, asindicated by block 58. The new loan may capture the revised terms whileleaving the previous version unchanged in memory, other than beingdesignated as overridden by the new smart contract in memory in someembodiments. In some cases, loan smart contracts may include logic tocheck for such records and may call an address of the new version of thesmart contract when invoked upon detecting such a record.

Some embodiments may create a new controlled wallet accountcorresponding to the forbearance version of the loan with the new termsand instantiate a new smart contract with the new forbearance terms, insome cases referencing the old smart contracts address. In some cases,the operations described herein may be subsequently be formed performedby operation of that forbearance smart contract with the new terms inplace of the current smart contract. As a result, in some cases, by bothparties' consent, while implementing operations on-chain or off-chain,flexibility may be afforded to the parties as they adjust the terms ofthe agreement in view of new information during the life of the loan, insome cases without being constrained by the immutable properties of manytypes of blockchain implemented records, like many forms of smartcontract.

In some embodiments, executing the smart contract may include verifyingthat code of the smart contract, like bytecode or source code, has notbeen modified by comparing a version requested to be executed againstrecords in the tamper-evident data structure to verify, for example,that cryptographic hash values match between the version to be executedand the version committed to the tamper-evident data structure, toverify that the correct code is being executed.

Upon instantiating a new loan with revised terms, embodiments mayterminate operation until the next invocation of block 34 in the process20 of FIG. 2 , in some cases with reference to the new loan withforbearance terms applied.

FIG. 4 illustrates an example of a computing environment 60 in whichtechniques like those described above may be implemented. In someembodiments, a loan-servicer system 62 may cooperate with a blockchaincomputing platform 74 to execute the processes of FIGS. 2 and 3 . Insome embodiments, the computing environment may include theloan-servicer system 62, the blockchain computing platform 74, aplurality of borrower computing devices 64, a lender computing device66, a payments oracle 68, a time oracle 70, and a price oracle 72, allof which may communicate via the internet 18. In some embodiments, thesecomponents may be organized and configured in the manner ofcorresponding components described above with reference to FIG. 1 , orin some cases they may be different, which is not to suggest that anyother description is limiting.

In some embodiments, there may be a plurality of borrower computingdevices 64. Three are shown, but embodiments are consistent withsubstantially more, like more than a million, or more than 10 million,geographically distributed over the United States or the world.Similarly, a single lender computing device 66 is shown, but embodimentsagain are consistent with substantially more, for instance, in similarnumbers to those described for the borrower computing device 64.

In some embodiments, the payments oracle 68 may be a server systemoperated by an entity that receives the payments or has access rights toan account with such an entity, like a bank. In some cases, the paymentsoracle 68 may include code that detects that a payment has been made,formats information into a schema ingestible by a smart contract or theloan-servicer system 62, cryptographically signs that information (forinstance, with a private cryptographic key of the payments oracle 68corresponding to a public key by which the payments oracle 68 isidentified to the blockchain computing platform 74 or the loan-servicersystem 62), and conveys that information to one or both of thoseentities. In some cases, the various oracles may further be configuredto selectively invoke registered callback functions specified by smartcontracts or the loan-servicer system 62 that invoke functionality, likeevent handlers to be run when new information is available from theoracles 68 through 72. Or in some embodiments, oracles 68 through 72 mayrespond to queries sent by these components 62 or 74 at a timedetermined by the loan-2servicer system 62 or a smart contract on theblockchain computing platform 74.

Similarly, the time oracle 70 may indicate a current time andcryptographically sign that current time with a private cryptographickey corresponding to public cryptographic key that serves to identifythe entity operating the time oracle. Or some embodiments may use a timedetermined by peer nodes with the above-described consensus protocols,like in a provably fair launch trigger based on block height orcoarse-grained (e.g., in 15 second quanta) consensus timestamps.

Similarly, the price oracle 72 may cryptographically sign priceinformation of a specified cryptographic assets, like that thedenominating the loan or that serving as collateral, or a ratio thereof.In some cases, the cryptographic signature may be made with a privatecryptographic key corresponding to public cryptographic key with whichthe price oracle 72 is identified to the blockchain computing platform74, the loan-servicer system 62, or both. Again, pricing information maybe sent responsive to invocation of a registered callback function orresponsive to a query sent by a smart contract or the loan-servicersystem 62.

As mentioned above, some embodiments may include additional oracles forother information, examples include an interest rate oracle for variableinterest rates, like LIBOR or SOFR. Other examples include informationcorresponding to various debt covenants, like in an amount of assets ina bank account, provided that appropriate permissions are granted by theaccount holder.

In some embodiments, the loan-servicer system 62 may include a webserver 76, an API server 78, a controller 80, a loan instantiator 84,collateral monitor 86, and a payment monitor 82.

Servers 76 and 78 may communicate with different types of counterparts(or in some cases, their functionality may be merged into a singleserver, which is not to suggest that any other feature described islimiting). In some embodiments, the web server 76 may serve webpagecontent by which user interfaces are supplied to the borrower computingdevice 64 and the lender computing device 66 for rendering in webbrowsers executing thereon. In some embodiments, the web server 76 mayfurther receive inputs conveyed via those web browsers back to theloan-servicer system 62. In some embodiments, the API server 78 mayinterface with a native application executing on user computing devices,like those of the borrower 64 or the lender 66. In some cases, APIserver 78, may also expose APIs by which the loan-servicer system 62interfaces with the blockchain computing platform 74 or other services.In some embodiments, the server 76 and 78 are implemented as nonblockingservers each monitoring a different port via different network sockets(e.g., having different port numbers), with nonblocking operations beingimplemented with promises or other deferreds.

In some embodiments, the controller 80 may coordinate the operation ofthe other components of the loan-servicer system 62, in some caseseffectuating some or all of the steps in FIGS. 2 and 3 and providinginput and receiving output via one or both of the servers 76 and 78.

In some embodiments, the loan instantiator 84 may effectuate thecreation of a secured (e.g., partially or fully secured) loan, forexample, by accessing a loan template, configuring the loan templateresponsive to information received from the borrower and lendercomputing devices 64 and 66, and transforming the template into aninstance of a smart contract with terms satisfying criteria of theborrower and of the lender. In some embodiments, lender criteria may bespecified programmatically, for example, with rules, and a rules enginemay populate the template, or in some cases, information to populate thetemplate may be provided via manual entry by humans operating devices 64and 66. Or in some cases, a loan schema specifies how the parties are toinput a loan, and a document encoding loan parameters may be receivedfrom devices 64 or 66 in the schema, e.g., in a hierarchical dataserialization format, like JavaScript™ object notation (JSON),extensible markup language (XML), yet another markup language (YAML), orthe like.

In some embodiments, the loan instantiator is 84 may operate a peer node(a term that is consistent with nodes in both federated andnon-federated architectures, e.g., some nodes may have different rolesor authorities while still being “peer nodes”) like those describedbelow with reference to FIG. 5 and may create the instance of the smartcontract on the blockchain computing platform 74 via that peer node. Forinstance, the smart contract may be created using an identifiercorresponding to the public cryptographic key of the control walletaccount or a public cryptographic key of the identity of the operator ofthe loan servicing system 62. In some cases, the smart contract may beassociated with the identity of the entity operating the loan-servicersystem 62 or the lender computing device 66, in some cases, drawing downan account of native cryptocurrency of the platform 74 of that entity tocompensate peer nodes for creating and running the smart contract, e.g.,consuming gas on Ethereum.

In some embodiments, the collateral monitor 86 may execute operationslike those described above with reference to FIG. 3 relating tomonitoring of the collateral. In some embodiments, these operations maybe invoked asynchronously relative to other forms of updating state ofthe loan. For example, collateral may be checked hourly, while paymentsmay be checked daily. In some embodiments, the collateral monitor 86 isconfigured to call an address of the smart contract on the blockchaincomputing platform 74 with parameters indicating that collateral is tobe checked and any arguments related thereto.

Some embodiments include the payment monitor 82, which may perform theoperations described above by which payments are verified and, in somecases, some forms of default are detected, for instance, those in whicha payment has not been received by a threshold time. Again, in someembodiments, the payment monitor 82 may call an address of the smartcontract of the loan to invoke corresponding functionality by whichpayment is verified. Or like the collateral monitor, some embodimentsmay implement these forms of monitoring off-chain, for example, in logicexecuted by the loan-servicer system 62, which may be external to theblockchain computing platform 74 (e.g., having a different address spaceand name space at the application layer and running in a different setof operating systems, in some cases, on different computing devices).

In some embodiments, the borrower computing device 64 and lendercomputing device 66 include an operating system 88 executing on one setof processors and a trusted execution environment 90 implemented with(e.g., executing on, or embodied by) another set of processors. The term“trusted” in “trusted execution environment” does not require anyparticular state of mind with regard to trust, but rather the phraserefers to a class of computing architectures that implement certaintechniques to securely store information, even in the face of attacksyielding escalated privileges in an OS. In some embodiments, the trustedexecution environment 90 executes on different processors from theoperating system 88, and in some cases, those different sets ofprocessors communicate via interrupts, with the processors executing thetrusted execution environment 90 having a different physical memoryaddress space than that accessible to the processors executing theoperating system 88. Thus, in some cases, a different physical memorybus (e.g., a plurality of parallel conductive paths) may connect theprocessors executing the operating system 88 to memory than thatconnecting the processors executing the trusted execution environment 90to a different body of memory. Such approaches are expected to impair orprevent certain attacks by which processes attempt to access informationoutside their address space, like buffer overflow attacks and row-hammerattacks.

In some embodiments, the operating system 88 may be the environment inwhich a native application 92 or a web browser 94 executes, and a userinterface may be presented by which borrowers and lenders may interfacewith the loan-servicer system 62 therein. In some embodiments, asdescribed below, these user interfaces may be part of a paymentprocessor website or a native application into which operations of theloan-servicer system 62 are integrated.

In some embodiments, the native application 92 may communicate with theAPI server 78, and in some cases, the web browser 74 may communicatewith the web server 76. In some cases, both applications 94 and 92 maycommunicate with both types of server 76 and 78.

FIG. 5 illustrates an example of the blockchain computing environment74, which in some embodiments, may be an example of the distributedledger 16 described above with reference to FIG. 1 . In someembodiments, the blockchain computing environment 74 supports aprogramming language by which program state is persisted to atamper-evident data store. In some cases, this programming language isTuring complete, or some embodiments may be non-Turing complete. Asshown in FIG. 5 , the blockchain computing platform 74 may beimplemented on a network of peer computing nodes 102. In someembodiments, the network may be an application layer network implementedon lower-level networks, like those below the application layer in theOpen Systems Interconnection model (OSI model). In some embodiments, thepeer nodes may each have the same role, or in some embodiments,different peer nodes 102 may have elevated authority and privileges, forexample, in certain federated architectures.

In some embodiments, each of the peer nodes may execute a peer clientapplication, such as virtual machine 104. In some embodiments, thevirtual machine 104 may shield those writing smart contracts fromneeding to contend with the particulars of the underlying physicalcomputing architecture and the operating system, thereby allowing asmart contract to, for example, run on both x86 and ARM™ architectures,or within both Linux™ and Windows™ operating systems, in some cases. Insome cases, each peer node may correspond to a different computingdevice, or in some cases, multiple peer nodes may execute on a singlecomputing device, e.g., as different instances of the virtual machine104. Reference to information being sent to or from addresses and thelike should be understood as including scenarios where transmission isbetween logical structures, e.g., between smart contracts both in memoryof a given peer node (and possibly several other, or all, peer nodes),without requiring transmission over a geographic distance betweenentities.

In some embodiments, the virtual machine 104 may include an interpreter106, a state machine 108, a tamper-evident data store 110 (which may bean example of the above-described tamper-evident data structures), and astack 112. In some embodiments, the interpreter may interpret sourcecode, like Solidity, Java™, or Go into an intermediate representation,like bytecode of the virtual machine 104, for example at runtime or inadvance. This may include parsing the source code, forming a concretesyntax tree (e.g., a parse tree) or an abstract syntax tree, andtransforming the result (in some cases, with optimizations, like loopunrolling) into bytecode executable by the virtual machine 104. In somecases, interpreting may include inserting bytecode instructions by whichan account of the entity invoking the smart contract has a nativecryptocurrency debited from their account to pay those operating peernodes for computation. The virtual machine may further include a programcounter that increments through an ordered list of the bytecodeinstructions, jumping to other positions therein as indicated bybranching logic therein in some cases. In some embodiments, suchexecution may cause state machine 108 to transition between variousstates, temporarily storing information in the stack 112 in, forexample, a last-in-first-out data structure. In some embodiments,information, like program state of smart contracts and accounts in whichcryptocurrency or other virtual cryptographic assets are held may bepersisted to (e.g., stored in a manner that remains accessible acrosssessions) the tamper-evident data store 110, which in some embodimentsmay be a blockchain.

An example of a blockchain 114 is illustrated in FIG. 5 . In someembodiments, the blockchain 114 may include a sequential list, like askip list, of blocks connected by cryptographic hash pointers. Acryptographic hash pointer may specify another node in a graph, likeanother block in a blockchain, and contain a cryptographic hash of (someor all of) the content of that other node, in some cases, includingcryptographic hash values of hash pointers from that node. Thus, a givenblock with a cryptographic hash pointer in a chain may have acryptographic hash value therein based upon each proceeding block. Insome embodiments, the chain may be initiated with a source of entropy,like a random seed value of greater than a threshold length.

In some embodiments, each block 116, 118, and 120 may include a headerwith the cryptographic hash pointer to the proceeding block and, forexample, a block sequence, a timestamp of when it was created, and otherblock particulars in some cases. In some embodiments, each block 116,118, and 120 may also include a value produced by a cryptographicaccumulator upon processing a collection of transactions 122. Examplesinclude a root of a Merkel tree, such as a radix tree.

FIG. 5 illustrates an example of a Merkel tree 126. In some embodiments,the Merkel tree 126 includes various types of directed acyclic graphs(like a trie, a radix tree, or a balanced binary tree) of cryptographichash pointers reachable from a root value 128. The root may have acryptographic hash value (or other one-way function output) based uponthe content of every single value in a tree data structure, therebyrendering all values in the tree tamper-evident. Further, the treestructure may expedite operations by which the absence of tampering isverified by constraining the number of hash values to be checked whenverifying a given leaf node 132, e.g., a given leaf node 132 may beverifiable by checking less than half of the hash values in the tree. Insome embodiments, the Merkel tree 126 may contain a plurality ofhierarchical layers, with each layer including a plurality of nodes thathave cryptographic hash pointers, and with each cryptographic hashpointers that is not a leaf node 132 pointing to two nodes in a lowerlevel of the hierarchy (e.g., in a balanced binary tree implementation).Intermediate layers are reference with the element number 130, as shownin FIG. 5 . Leaf nodes 132 may each include the information beingrendered tamper-evident or cryptographic hashes thereof or other outputsof one-way functions. In some embodiments, the leaf nodes 132 mayindicate transactions or account states. For example, the current ownerof a unit of cryptocurrency may be determined by tracing transactionsreferenced in the leaf nodes to the minting of the cryptocurrency, orwith a state of an account documented in a leaf node 132. In someembodiments, each transaction pertaining to a given unit ofcryptocurrency may reference a proceeding transaction (e.g., byidentifying a block and leaf node) involving that cryptocurrency,thereby forming a graph of transactions. Similarly, each referenceupdating the state of an account, for instance, indicating an amount ofcryptocurrency in that account may reference a proceeding state of thataccount in a linked list.

A single Merkel tree 126 is shown for a block, but some embodiments mayinclude multiple Merkel trees with multiple Merkel roots in each block.For example, some embodiments may have three, with each treecorresponding to a different type of data in the blockchain computingplatform 74. In some embodiments, a given block may include a Merkelroot for a transaction tree, such as a root of a radix tree ofcryptographic hash pointers with transactions rendered tamper evident inleaf nodes. Some embodiments may include further a root of a radix treeof cryptographic hash pointers rendering updated state in leaf nodestamper evident, for example, the root of a storage radix tree. Further,some embodiments may include a third root value of a radix tree ofcryptographic hash pointers for receipts corresponding to acquisitionand consumption of a native cryptocurrency consumed when executingoperations on smart contracts or awarded for operating a peer node, likegas in Ethereum. In some embodiments, the transaction tree may referencereceipts in which gas is consumed to run the corresponding transactionor vice versa and state in the state tree indicating changes in smartcontract state or vice versa. Or some embodiments may be implementedwithout gas, for instance, using certain forms of Hyperledger.

FIG. 6 illustrates an example computing environment 150 in which theloan-servicer systems described above may be implemented. In someembodiments, the above loan-servicer system 62 may be part of a paymentprocessor system 152 in which credit card payments are processed incooperation with a card network 156 on behalf of sellers operatingseller computing device 154. A single card network 156 is shown, butembodiments are consistent with more, and a single seller computingdevice 154 shown, but embodiments are consistent with substantiallymore, for example, more than 10,000, more than a million, or more than10 million seller computing devices interacting with the paymentprocessor 152. In some embodiments, the payment processor may encodevarious forms of value of the seller, like obligations of the paymentprocessor or the card holder to the seller, like accounts receivable incryptocurrency, and in some cases, the payment processor may implement aloan secured by that cryptocurrency, with the loan-servicer system 62interacting with the other components described above in some cases. Insome cases, sellers may accumulate value in their account with thepayment processor, like over the month before disbursement, and thatvalue may be represented as a cryptocurrency which may serve as thecollateral described above to support loans against those obligations.In another example, sellers may have their payments issued in the formof a cryptocurrency to a wallet account of the seller, and theloan-servicer system 62 may be configured to issue loans secured bycollateral from those wallet accounts for sellers in need of debtfinancing.

In some cases, even with the pseudonymity afforded by certain forms ofdistributed ledger technology, borrowers and lenders may be sensitive toprivacy concerns, particularly when the distributed ledger technology isa public implementation, like a public blockchain computing platform. Aborrower may not wish others to know an aggregate amount of debtassociated with their identity. To mitigate these concerns, someembodiments may implement homomorphic encryption techniques to maintainsome or all of the logic of the lending agreement on-chain withoutrevealing parameters of the lending agreement. For example, some of theabove threshold determinations (like whether loan-to-value criteria aresatisfied or whether a loan obligation has been satisfied) may beimplemented by using various solution to Yao's Millionaires' problem todetermine whether one encrypted amount is larger than another withouthaving access to plaintext representations of the amounts, examplesincluding Hsiao-Ying Lin and Wen-Guey Tzeng's protocol, loannidis andAnanth's protocol, and Hsiao-Ying Lin and Wen-Guey Tzeng's protocolbased on ElGamal encryption. In some embodiments accrued interest andother multiplication operations may be calculated homomorphically aswell, for example, by encrypting values to be multiplied (like aninterest rate and loan balance) with ElGamal encryption, which supportshomomorphic operations with respect to multiplication in some cases.Similarly, in some cases accrued payments may be summed with additivelyhomomorphic ElGamal encryption performed on-chain without revealingplaintext parameters of the loan on a public implementation ofdistributed ledger technology.

In block diagrams, illustrated components are depicted as discretefunctional blocks, but embodiments are not limited to systems in whichthe functionality described herein is organized as illustrated. Thefunctionality provided by each of the components may be provided bysoftware or hardware modules that are differently organized than ispresently depicted, for example such software or hardware may beintermingled, conjoined, replicated, broken up, distributed (e.g. withina data center or geographically), or otherwise differently organized.The functionality described herein may be provided by one or moreprocessors of one or more computers executing code stored on a tangible,non-transitory, machine readable medium. In some cases, notwithstandinguse of the singular term “medium,” the instructions may be distributedon different storage devices associated with different computingdevices, for instance, with each computing device having a differentsubset of the instructions, an implementation consistent with usage ofthe singular term “medium” herein. In some cases, third party contentdelivery networks may host some or all of the information conveyed overnetworks, in which case, to the extent information (e.g., content) issaid to be supplied or otherwise provided, the information may providedby sending instructions to retrieve that information from a contentdelivery network.

The reader should appreciate that the present application describesseveral independently useful techniques. Rather than separating thosetechniques into multiple isolated patent applications, applicants havegrouped these techniques into a single document because their relatedsubject matter lends itself to economies in the application process. Butthe distinct advantages and aspects of such techniques should not beconflated. In some cases, embodiments address all of the deficienciesnoted herein, but it should be understood that the techniques areindependently useful, and some embodiments address only a subset of suchproblems or offer other, unmentioned benefits that will be apparent tothose of skill in the art reviewing the present disclosure. Due to costsconstraints, some techniques disclosed herein may not be presentlyclaimed and may be claimed in later filings, such as continuationapplications or by amending the present claims. Similarly, due to spaceconstraints, neither the Abstract nor the Summary of the Inventionsections of the present document should be taken as containing acomprehensive listing of all such techniques or all aspects of suchtechniques.

It should be understood that the description and the drawings are notintended to limit the present techniques to the particular formdisclosed, but to the contrary, the intention is to cover allmodifications, equivalents, and alternatives falling within the spiritand scope of the present techniques as defined by the appended claims.Further modifications and alternative embodiments of various aspects ofthe techniques will be apparent to those skilled in the art in view ofthis description. Accordingly, this description and the drawings are tobe construed as illustrative only and are for the purpose of teachingthose skilled in the art the general manner of carrying out the presenttechniques. It is to be understood that the forms of the presenttechniques shown and described herein are to be taken as examples ofembodiments. Elements and materials may be substituted for thoseillustrated and described herein, parts and processes may be reversed oromitted, and certain features of the present techniques may be utilizedindependently, all as would be apparent to one skilled in the art afterhaving the benefit of this description of the present techniques.Changes may be made in the elements described herein without departingfrom the spirit and scope of the present techniques as described in thefollowing claims. Headings used herein are for organizational purposesonly and are not meant to be used to limit the scope of the description.

As used throughout this application, the word “may” is used in apermissive sense (i.e., meaning having the potential to), rather thanthe mandatory sense (i.e., meaning must). The words “include”,“including”, and “includes” and the like mean including, but not limitedto. As used throughout this application, the singular forms “a,” “an,”and “the” include plural referents unless the content explicitlyindicates otherwise. Thus, for example, reference to “an element” or “aelement” includes a combination of two or more elements, notwithstandinguse of other terms and phrases for one or more elements, such as “one ormore.” The term “or” is, unless indicated otherwise, non-exclusive,i.e., encompassing both “and” and “or.” Terms describing conditionalrelationships, e.g., “in response to X, Y,” “upon X, Y,”, “if X, Y,”“when X, Y,” and the like, encompass causal relationships in which theantecedent is a necessary causal condition, the antecedent is asufficient causal condition, or the antecedent is a contributory causalcondition of the consequent, e.g., “state X occurs upon condition Yobtaining” is generic to “X occurs solely upon Y” and “X occurs upon Yand Z.” Such conditional relationships are not limited to consequencesthat instantly follow the antecedent obtaining, as some consequences maybe delayed, and in conditional statements, antecedents are connected totheir consequents, e.g., the antecedent is relevant to the likelihood ofthe consequent occurring. Statements in which a plurality of attributesor functions are mapped to a plurality of objects (e.g., one or moreprocessors performing steps A, B, C, and D) encompasses both all suchattributes or functions being mapped to all such objects and subsets ofthe attributes or functions being mapped to subsets of the attributes orfunctions (e.g., both all processors each performing steps A-D, and acase in which processor 1 performs step A, processor 2 performs step Band part of step C, and processor 3 performs part of step C and step D),unless otherwise indicated. Similarly, reference to “a computer system”performing step A and “the computer system” performing step B caninclude the same computing device within the computer system performingboth steps or different computing devices within the computer systemperforming steps A and B. Further, unless otherwise indicated,statements that one value or action is “based on” another condition orvalue encompass both instances in which the condition or value is thesole factor and instances in which the condition or value is one factoramong a plurality of factors. Unless otherwise indicated, statementsthat “each” instance of some collection have some property should not beread to exclude cases where some otherwise identical or similar membersof a larger collection do not have the property, i.e., each does notnecessarily mean each and every. Limitations as to sequence of recitedsteps should not be read into the claims unless explicitly specified,e.g., with explicit language like “after performing X, performing Y,” incontrast to statements that might be improperly argued to imply sequencelimitations, like “performing X on items, performing Y on the X'editems,” used for purposes of making claims more readable rather thanspecifying sequence. Statements referring to “at least Z of A, B, andC,” and the like (e.g., “at least Z of A, B, or C”), refer to at least Zof the listed categories (A, B, and C) and do not require at least Zunits in each category. Unless specifically stated otherwise, asapparent from the discussion, it is appreciated that throughout thisspecification discussions utilizing terms such as “processing,”“computing,” “calculating,” “determining” or the like refer to actionsor processes of a specific apparatus, such as a special purpose computeror a similar special purpose electronic processing/computing device.Features described with reference to geometric constructs, like“parallel,” “perpendicular/orthogonal,” “square”, “cylindrical,” and thelike, should be construed as encompassing items that substantiallyembody the properties of the geometric construct, e.g., reference to“parallel” surfaces encompasses substantially parallel surfaces. Thepermitted range of deviation from Platonic ideals of these geometricconstructs is to be determined with reference to ranges in thespecification, and where such ranges are not stated, with reference toindustry norms in the field of use, and where such ranges are notdefined, with reference to industry norms in the field of manufacturingof the designated feature, and where such ranges are not defined,features substantially embodying a geometric construct should beconstrued to include those features within 15% of the definingattributes of that geometric construct. The terms “first”, “second”,“third,” “given” and so on, if used in the claims, are used todistinguish or otherwise identify, and not to show a sequential ornumerical limitation. As is the case in ordinary usage in the field,data structures and formats described with reference to uses salient toa human need not be presented in a human-intelligible format toconstitute the described data structure or format, e.g., text need notbe rendered or even encoded in Unicode or ASCII to constitute text;images, maps, and data-visualizations need not be displayed or decodedto constitute images, maps, and data-visualizations, respectively;speech, music, and other audio need not be emitted through a speaker ordecoded to constitute speech, music, or other audio, respectively.Computer implemented instructions, commands, and the like are notlimited to executable code and can be implemented in the form of datathat causes functionality to be invoked, e.g., in the form of argumentsof a function or API call. To the extent bespoke noun phrases (and othercoined terms) are used in the claims and lack a self-evidentconstruction, the definition of such phrases may be recited in the claimitself, in which case, the use of such bespoke noun phrases should notbe taken as invitation to impart additional limitations by looking tothe specification or extrinsic evidence.

What is claimed is:
 1. A system comprising one or more processors and anon-transitory computer-readable memory communicatively coupled with theone or more processors, the memory comprising instructions that, whenexecuted by the one or more processors, cause the one or more processorsto perform operations comprising: obtaining parameters of a firstsecured obligation of an obligor, the parameters including a firstobligee, an obligation of the obligor to the first obligee, and a set ofcryptographic assets to secure the obligation; causing the set ofcryptographic assets to be placed under control of the first obligee ina distributed computing platform by transferring the set ofcryptographic assets from an account owned by the obligor to an accountowned at least in part by the first obligee, wherein the account ownedat least in part by the first obligee corresponds to a cryptographic keypair of an asymmetric encryption algorithm, the cryptographic key pairhaving a public cryptographic key and a private cryptographic key,wherein the obligor is not provided access to the private cryptographickey before at least some of the obligation of the obligor to the obligeeis satisfied, and wherein the transfer is recorded in a distributedledger maintained by the decentralized computing platform; obtainingparameters of a second secured obligation of the obligor, the parametersincluding a second obligee, an obligation of the obligor to the secondobligee, and at least a portion of the set of cryptographic assets tosecure the obligation; instantiating a smart contract with thedecentralized computing platform to be executed when at least some ofthe obligation of the obligor to the first obligee is satisfied, thesmart contract comprising a transfer of the at least a portion of theset of cryptographic assets from the account owned at least in part bythe first obligee to an account owned at least in part by the secondobligee; determining that at least some of the obligation of the obligorto the first obligee has been satisfied; and causing execution of thesmart contract.
 2. The system of claim 1, wherein the distributedcomputing platform is configured to require proof of access to a privatecryptographic key to transfer assets from a corresponding account. 3.The system of claim 1, wherein the account owned at least in part by thesecond obligee corresponds to a second cryptographic key pair of anasymmetric encryption algorithm, the second cryptographic key pairhaving a second public cryptographic key and a second privatecryptographic key, and wherein the instructions further cause the one ormore processors to perform further operations comprising: afterexecution of the smart contract and in response to determining that atleast some of the obligation of the obligor to the second obligee hasbeen satisfied, providing, to the user, access to the second privatecryptographic key.
 4. The system of claim 1, wherein the instructionsfurther cause the one or more processors to perform further operationscomprising: determining that at least some of the obligation of theobligor to the first obligee has been satisfied using homomorphicencryption such that terms of the obligation of the obligor to the firstobligee are not made public.
 5. The system of claim 1, wherein theinstructions further cause the one or more processors to perform furtheroperations comprising: creating, in response to obtaining the parametersof the first secured obligation of the obligor, the account owned atleast in part by the first obligee with the decentralized computingplatform.
 6. The system of claim 1, wherein the account owned at leastin part by the first obligee is further owned at least in part by theobligor.
 7. The system of claim 1, wherein the account owned at least inpart by the first obligee is further owned at least in part by a loanservicer.
 8. The system of claim 1, wherein the transfer of the set ofcryptographic assets from the account owned by the obligor to theaccount owned at least in part by the first obligee is effectuated bycausing data with which control of the account owned at least in partyby the first obligee is effectuated to be rendered tamper evident by adirected acyclic graph of cryptographic hash pointers.
 9. The system ofclaim 1, wherein: transferring the set of cryptographic assets from theaccount owned by the obligor to the account owned at least in part bythe first obligee comprises calling a program executed by thedecentralized computing platform; the decentralized computing platformis hosted by a plurality of different computing devices; and a subset ofthe plurality of different computing devices redundantly execute theprogram responsive to the call and determine a result of executing theprogram by selecting among outcomes of executing the program produced bydifferent computing devices with a consensus protocol.
 10. The system ofclaim 1, wherein: the second obligee is the first obligee, and theobligation of the obligor to the second obligee corresponds to amodification of the obligation of the obligor to the first obligee; andthe smart contract is further instantiated with the decentralizedcomputing platform to be executed when at least some of the obligationof the obligor to the first obligee is discharged by the first obligee.11. A computer-implemented method comprising: obtaining parameters of afirst secured obligation of an obligor, the parameters including a firstobligee, an obligation of the obligor to the first obligee, and a set ofcryptographic assets to secure the obligation; causing the set ofcryptographic assets to be placed under control of the first obligee ina distributed computing platform by transferring the set ofcryptographic assets from an account owned by the obligor to an accountowned at least in part by the first obligee, wherein the account ownedat least in part by the first obligee corresponds to a cryptographic keypair of an asymmetric encryption algorithm, the cryptographic key pairhaving a public cryptographic key and a private cryptographic key,wherein the obligor is not provided access to the private cryptographickey before at least some of the obligation of the obligor to the obligeeis satisfied, and wherein the transfer is recorded in a distributedledger maintained by the decentralized computing platform; obtainingparameters of a second secured obligation of the obligor, the parametersincluding a second obligee, an obligation of the obligor to the secondobligee, and at least a portion of the set of cryptographic assets tosecure the obligation; instantiating a smart contract with thedecentralized computing platform to be executed when at least some ofthe obligation of the obligor to the first obligee is satisfied, thesmart contract comprising a transfer of the at least a portion of theset of cryptographic assets from the account owned at least in part bythe first obligee to an account owned at least in part by the secondobligee; determining that at least some of the obligation of the obligorto the first obligee has been satisfied; and causing execution of thesmart contract.
 12. The method of claim 11, wherein the distributedcomputing platform is configured to require proof of access to a privatecryptographic key to transfer assets from a corresponding account. 13.The method of claim 11, wherein the account owned at least in part bythe second obligee corresponds to a second cryptographic key pair of anasymmetric encryption algorithm, the second cryptographic key pairhaving a second public cryptographic key and a second privatecryptographic key, the method further comprising: after execution of thesmart contract and in response to determining that at least some of theobligation of the obligor to the second obligee has been satisfied,providing, to the user, access to the second private cryptographic key.14. The method of claim 11, further comprising: determining that atleast some of the obligation of the obligor to the first obligee hasbeen satisfied using homomorphic encryption such that terms of theobligation of the obligor to the first obligee are not made public. 15.The method of claim 11, further comprising: creating, in response toobtaining the parameters of the first secured obligation of the obligor,the account owned at least in part by the first obligee with thedecentralized computing platform.
 16. A non-transitory,computer-readable medium storing instructions that, when executed,effectuate operations comprising: obtaining parameters of a firstsecured obligation of an obligor, the parameters including a firstobligee, an obligation of the obligor to the first obligee, and a set ofcryptographic assets to secure the obligation; causing the set ofcryptographic assets to be placed under control of the first obligee ina distributed computing platform by transferring the set ofcryptographic assets from an account owned by the obligor to an accountowned at least in part by the first obligee, wherein the account ownedat least in part by the first obligee corresponds to a cryptographic keypair of an asymmetric encryption algorithm, the cryptographic key pairhaving a public cryptographic key and a private cryptographic key,wherein the obligor is not provided access to the private cryptographickey before at least some of the obligation of the obligor to the obligeeis satisfied, and wherein the transfer is recorded in a distributedledger maintained by the decentralized computing platform; obtainingparameters of a second secured obligation of the obligor, the parametersincluding a second obligee, an obligation of the obligor to the secondobligee, and at least a portion of the set of cryptographic assets tosecure the obligation; instantiating a smart contract with thedecentralized computing platform to be executed when at least some ofthe obligation of the obligor to the first obligee is satisfied, thesmart contract comprising a transfer of the at least a portion of theset of cryptographic assets from the account owned at least in part bythe first obligee to an account owned at least in part by the secondobligee; determining that at least some of the obligation of the obligorto the first obligee has been satisfied; and causing execution of thesmart contract.
 17. The non-transitory, computer-readable medium ofclaim 16, wherein the distributed computing platform is configured torequire proof of access to a private cryptographic key to transferassets from a corresponding account.
 18. The non-transitory,computer-readable medium of claim 16, wherein the account owned at leastin part by the second obligee corresponds to a second cryptographic keypair of an asymmetric encryption algorithm, the second cryptographic keypair having a second public cryptographic key and a second privatecryptographic key, and the instructions further effectuate operationsfurther comprising: after execution of the smart contract and inresponse to determining that at least some of the obligation of theobligor to the second obligee has been satisfied, providing, to theuser, access to the second private cryptographic key.
 19. Thenon-transitory, computer-readable medium of claim 16, wherein theinstructions further effectuate operations further comprising:determining that at least some of the obligation of the obligor to thefirst obligee has been satisfied using homomorphic encryption such thatterms of the obligation of the obligor to the first obligee are not madepublic.
 20. The non-transitory, computer-readable medium of claim 16,wherein the instructions further effectuate operations furthercomprising: creating, in response to obtaining the parameters of thefirst secured obligation of the obligor, the account owned at least inpart by the first obligee with the decentralized computing platform.